home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0079 / 761.txt < prev    next >
Text File  |  1997-04-16  |  15KB  |  349 lines
  1. INFO-ATARI16 Digest         Wed,  6 Dec 89       Volume 89 : Issue 761
  2.  
  3. Today's Topics:
  4.                          1040st sound problem
  5.                       Atracting new Club members
  6.                               C question
  7.                               Form Doc's
  8.                        LYNX Development System
  9.                         Shareware MAC (3 msgs)
  10.                   Sozobon C, PageStream, Magic, NRPS
  11. ----------------------------------------------------------------------
  12.  
  13. Date: 6 Dec 89 01:25:57 GMT
  14. From:
  15.  usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632!rit!ultb!drp9
  16.  500@ucsd.edu  (D.R. Paradis)
  17. Subject: 1040st sound problem
  18. Message-ID: <1698@ultb.isc.rit.edu>
  19.  
  20.   I forget the part number but it is the General Instruments sound chip
  21. from Radio Shack.
  22.  
  23.    how do I know this......I had to replace mine and used this chip and
  24. it's been working like a champ for over a year!
  25.  
  26.   The chip is about $10 (standard 40 pin size) but they do have it.
  27.  
  28. ------------------------------
  29.  
  30. Date: 6 Dec 89 17:54:42 GMT
  31. From: texbell!wuarchive!kuhub.cc.ukans.edu!shawl@rutgers.edu
  32. Subject: Atracting new Club members
  33. Message-ID: <19367@kuhub.cc.ukans.edu>
  34.  
  35. The Lawrence Atari Computer Club (Lawrence, Kansas) meets in the
  36. public library.  I would recommend trying that since it is
  37. centrally located, and FREE!!
  38.  
  39. Steve Shawl
  40. bitnet:  Shawl@kuhub.cc.ukans.edu
  41.  
  42. ------------------------------
  43.  
  44. Date: 6 Dec 89 17:45:24 GMT
  45. From: galaxy.rutgers.edu!argus!ron@rutgers.edu  (Ron DeBlock)
  46. Subject: C question
  47. Message-ID: <1381@argus.UUCP>
  48.  
  49. Someone asked why
  50.         main()
  51.         ?
  52.                 char fred[] = "hello";
  53.                 ....
  54. won't work, and a bunch of answers followed.  Some made no sense, others
  55. were close, but I haven't seen the complete answere yet.  So here it is:
  56.  
  57.  
  58. The error from the compiler on this line is probably something like:
  59.         "No initialization of automatic agragate."
  60.  
  61. This means that an aggragate structure (an arry, struct or union) that is
  62. automatically allocat cannot be pre-initialized.  Automatics are any
  63. variables declared INSIDE of a function (this excludes the functions
  64. arguments).  For non-aggragate variables, (int, *, cha the compiler
  65. will generate storage and code to initialize.  It does not do so for
  66. aggragates.
  67.  
  68. The solution is to make the variable non-automatic.  Someone mentioned
  69. declaring the array as
  70.         static char fred[]
  71. which will work just fine.  Global variables are also not automatic,
  72. so moving the declaration outside of main() will also work.
  73.  
  74. C provides the keyword "auto" to make variables automatic.  I've
  75. never seen it used, since it is only valid within functi (or block)
  76. scope and it is the default.
  77.  
  78. The "static" keyword has an interesting side effect: a global symbol
  79. declared as static only has file scope.  This allows you to create
  80. global vaiables and functions which are visible only within a file:
  81.  
  82.         static int foo;
  83.         int bar;
  84.  
  85.         static int bas()
  86.         ?
  87.                 ...
  88.         ?
  89.  
  90.         int baf()
  91.         ?
  92.                 ...
  93.         ?
  94.  
  95.  
  96.  
  97. baf() and bar may be declareas extern in other files and used normally.
  98. However, foo and bas() CANNOT be referenced outside of the file!  This is
  99. sometimes useful if you want to be sure that certain variables or functions
  100. cannot be accessed from other code.
  101. --
  102. Ron DeBlock     N2JSO
  103. Net: ...!rutgers!galaxy!argus
  104. US Mail: 42 Davis Street, Phillibsburg, NJ 08865 USA
  105.  
  106. ------------------------------
  107.  
  108. Date: 6 Dec 89 05:11:21 GMT
  109. From: att!chinet!saj@ucbvax.Berkeley.EDU  (Stephen Jacobs)
  110. Subject: Form Doc's
  111. Message-ID: <1989Dec6.051121.21994@chinet.chi.il.us>
  112.  
  113. I can whine with the best of them (and do, often enough).  The point that .dvi
  114. isn't the most accessible form seems made.  For those who can do nothing else,
  115. i suggest using either a strings program or a dump utility on the dvi: enough
  116. of the text is recoverable to let you know what the program is about.
  117.                                  Steve J.
  118.  
  119. ------------------------------
  120.  
  121. Date: 5 Dec 89 13:10:41 GMT
  122. From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU  (Michael
  123.  Portuesi)
  124. Subject: LYNX Development System
  125. Message-ID: <PORTUESI.89Dec5131041@tweezers.esd.sgi.com>
  126.  
  127. >>>>> On 5 Dec 89 17:44:45 GMT, 2FHDBEAK@kuhub.cc.ukans.edu said:
  128. j> Here's an interesting tidbit for you LYNX fans:
  129.  
  130. j> The development system for the Atari LYNX is an AMIGA computer!
  131. j> I wonder what it must be like to go into Atari's offices and see
  132. j> all sorts of Amigas lying about.
  133.  
  134.  
  135. That's not surprising, given that the Lynx was developed at Epyx, not
  136. Atari, and all the Lynx designers also designed the Amiga.
  137.  
  138.                                 --M
  139. --
  140. __
  141. \/  Michael Portuesi    Silicon Graphics Computer Systems, Inc.
  142.     portuesi@SGI.COM    Entry Systems Division -- Engineering
  143.  
  144. He says, "Take me to your leader" -- and I say, "Do you mean....George?"
  145.  
  146. ------------------------------
  147.  
  148. Date: 5 Dec 89 16:15:15 GMT
  149. From: att!drutx!druwy!dlm@ucbvax.Berkeley.EDU  (Dan Moore)
  150. Subject: Shareware MAC
  151. Message-ID: <4476@druwy.ATT.COM>
  152.  
  153. in article <3395@brazos.Rice.edu>, bro@titan.rice.edu (Douglas Monk) says:
  154. > The suggestion was made that instead of using a cartridge, code that works
  155. > like the MAC ROMs but doesn't violate Apple's copyright could be used. This
  156. > is a great idea. No one has done it yet, which is one of the reasons why no
  157. > Apple clones (other than STs :-) exist yet.
  158.                 ~~~~~~~~~~~~~~ not true, there is an Amiga Mac emulator.
  159.  
  160. > It is a technical difficulty, or a legal one? How does Phoenix et al. get
  161. > away with IBM clone ROMs? Licensing? Work-alike?
  162.  
  163.         The problem is partly technical and partly legal (or at least
  164. lots of money for lawyers).
  165.  
  166.         To "legally clone" a BIOS (or ToolBox in Mac'ese) you need to
  167. teams of programmers and some lawyers.  The first team studies the code
  168. to be duplicated and generates a highly detailed description of the
  169. code.  The description would include statements about register
  170. contents, data structures passed, etc. for the various routines in the
  171. BIOS.  It then states what the routine does including any side effects
  172. (eg. global variables that are changed).  It should also document any
  173. bugs in the code (ie. deviations from the published specifications for
  174. the BIOS). This description is then sent to the lawyers who save copies
  175. of everything (documentation for any suits that come up) and then send
  176. a copy to the second programmer team.  The second progammer team has to
  177. be made up of people who have NEVER looked at the actual code to be
  178. duplicated (ie. they never used a debugger to look at the Mac ROMs or
  179. the IBM PC BIOS or whatever).  They also can NOT talk to the first
  180. programmer team except by having the lawyers forward messages (which
  181. are filed just like everything else.)  They then use the descriptions
  182. to write routines that do the exact same thing as the original.  They
  183. may even clone the bugs, some of the 3rd party EGA cards for PC's have
  184. the same bugs as IBM's EGA card.
  185.  
  186.         When you get done you have what should be a legal duplicate of
  187. the first program's functionality.  There may be problems due to
  188. copyrights on the visual appearance (look & feel) or patents on
  189. algorithims, etc.  Hopefully the documentation the lawyers have will be
  190. enough to prove that you did things legally (Phoenix pulled it off with
  191. BIOS ROMs for PC's).
  192.  
  193.         The technical problems are really just time problems.  The Mac
  194. ROMs are very complex (much more complicated than the TOS ROMs for
  195. instance).  Given the large number of functions contained in the ROMs
  196. it will take quite a while to duplicate them. And while they are
  197. working to duplicate a given release of ROMs (eg. the 256K ROMs in the
  198. Mac II) Apple will be working on new, improved ROMs with new features.
  199. So when you get done you may have something that is already obsolete.
  200. This isn't a problem with cloning the BIOS ROMs in a PC, the functions
  201. of those ROMs is pretty stable with very few changes over time.
  202.  
  203.  
  204.         No company has decided that the time and expense (at least one
  205. year, at least 10 or 20 programmers, plus lawyers, and Apple will
  206. sue when you get done) is worth the expected return.
  207.  
  208.  
  209.  
  210.                                 Dan Moore
  211.                                 AT&T Bell Labs
  212.                                 Denver
  213.                                 dlm@druwy.ATT.COM
  214.  
  215. ------------------------------
  216.  
  217. Date: 4 Dec 89 15:34:59 GMT
  218. From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU  (Michael
  219.  Portuesi)
  220. Subject: Shareware MAC
  221. Message-ID: <PORTUESI.89Dec4153459@tweezers.esd.sgi.com>
  222.  
  223. >>>>> On 29 Nov 89 14:30:00 GMT, greg.trice@canremote.uucp (GREG TRICE) said:
  224.  
  225. greg> Why does everybody assume that a Mac emulator has to use Mac ROMs or any
  226. greg> Mac code at all? There are an infinite number of ways to do a given job
  227. greg> and it is perfectly possible for somebody to carefully read all the Mac
  228. greg> documentation and then sit down and write code that will do exactly the
  229. greg> same job as the Mac roms, but have not a byte in common with them in
  230. greg> code. This is the situation with most IBM compatible systems. Though
  231. greg> they are functionally identical to the IBM product, their ROMs contain
  232. greg> different, but functionally identical code.
  233. greg>  It should be perfectly possible to produce a Mac emulator that used no
  234. greg> ROMs at all, but was wholly disk based (given sufficient memory to hold
  235. greg> the quondam ROM code in RAM).
  236.  
  237.  
  238. Go ahead and try...I'll see you in a few years.
  239.  
  240. The Apple ROMS are the result of several hundred person-years of work,
  241. and you expect one enterprising hacker to recode them, and do all
  242. of the testing and revising to ensure even a reasonable amount of
  243. compatibilty?  Obviously you've never developed software for a living.
  244.  
  245.                                 --M
  246. --
  247. __
  248. \/  Michael Portuesi    Silicon Graphics Computer Systems, Inc.
  249.     portuesi@SGI.COM    Entry Systems Division -- Engineering
  250.  
  251. He says, "Take me to your leader" -- and I say, "Do you mean....George?"
  252.  
  253. ------------------------------
  254.  
  255. Date: 6 Dec 89 17:35:00 GMT
  256. From: apollo!rehrauer@eddie.mit.edu  (Steve Rehrauer)
  257. Subject: Shareware MAC
  258. Message-ID: <474461c0.20b6d@apollo.HP.COM>
  259.  
  260. In article <3395@brazos.Rice.edu> bro@titan.rice.edu (Douglas Monk) writes:
  261. >The suggestion was made that instead of using a cartridge, code that works
  262. >like the MAC ROMs but doesn't violate Apple's copyright could be used. This
  263. >is a great idea. No one has done it yet, which is one of the reasons why no
  264. >Apple clones (other than STs :-) exist yet.
  265. >
  266. >It is a technical difficulty, or a legal one?
  267.  
  268. Primarily the former, secondarily the latter.  To "do it right"; i.e.: to
  269. avoid committing legal hari-kari, companies use what I've heard called a
  270. "clean room" approach.  Two design teams work on the problem.  Team #1
  271. looks at the *specifications* for what they're trying to clone.  It's
  272. probably fair for this team to look at ROM images, but I'm sure it'd be
  273. better if they didn't.  Team #1 generates their own specs for how to
  274. functionally reproduce what is to be cloned.  Team #2 only sees this
  275. spec, and can never look at the original materials team #1 used.  No
  276. fair going to team #1 and saying, "Hey, we're having a hard time seeing
  277. how to do 'bletch'; how did They do it?"  If the original specs were
  278. accurate, and team #1 did a good job, and team #2 did a good job, the
  279. clone works well.
  280.  
  281. And even after all that, if the opposition is sufficiently larger than
  282. yourself, they may be able bleed you dry in court.  You may be perfectly
  283. legal in what you've done, but proving it takes time and $$$.
  284.  
  285. > How does Phoenix et al. get
  286. >away with IBM clone ROMs? Licensing? Work-alike?
  287.  
  288. What's in IBM ROM BIOS is surely an order of magnitude (or more) easier
  289. to reverse-engineer than what's in Mac ROMs.  Not to mention that it's
  290. (at least originally, and perhaps still) far more lucrative if you succeed
  291. with IBM BIOS.
  292.  
  293. Don't hold your breath for Mac OS clones.  Apple has shown itself to be
  294. quite willing to vigorously defend what it considers its turf, whether
  295. "common sense" says they have a case or not.  The cost of developing a
  296. Mac clone "done right", plus the possibility of locking horns with Apple
  297. in court afterwards, is enough to scare away most of the cloners.  I'd
  298. expect to see Apple license their ROMs before we see clones, and they
  299. haven't been too receptive to that idea either.
  300.  
  301. --
  302. >>"Aaiiyeeee!  Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com
  303.    "Flee, lest we be trod upon!"    | The Apollo System Division of H.P.
  304.  
  305. ------------------------------
  306.  
  307. Date: 5 Dec 89 11:00:00 GMT
  308. From:
  309.  ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!glk01126@iuvax.cs.indiana.ed
  310.  u
  311. Subject: Sozobon C, PageStream, Magic, NRPS
  312. Message-ID: <111500076@uxa.cso.uiuc.edu>
  313.  
  314.         To the authors of Sozobon: great job on version 1.2, when
  315.         is the final release coming?
  316.  
  317.         I have finally deceiphered the format of PageStream files
  318.         and wrote (for a class) a magic (VLSI CAD SYSTEM) to PageStream
  319.         file converter if anyone is interested.  This will allow
  320.         you to work on VLSI in a PageStream Document and port it...
  321.         (with limited error checking) or to include your VLSI documents
  322.         in PageStream documents.
  323.  
  324.         I am going to start a graphing program that will output to
  325.         PageStream format files.  I have not decided yet if I should
  326.         try to contact SoftLogic for possible marketing (GraphStream)
  327.         or release it as shareware... Anyone have any advice?
  328.  
  329.         Has anyone done any reviews on products and sent them in to
  330.         a magazine?  I would like to review Sozobon C and get the
  331.         message out that an excellent PD C is available.
  332.  
  333.         To the requesters of Neodesk Random Picture Selector... It
  334.         is available at terminator (35.1.33.8) in atari/new/nrps.arc.
  335.         Version 2.0 is coming soon that will extract a random picture
  336.         from .zoo,.lzh or .arc files and use that. (getting sick of
  337.         all the space required for the pictures)  If you can't access
  338.         terminator, get your request to me or let me know how to post
  339.         it to comp.binaries.atari.st.
  340.  
  341.  
  342.         -Gregory Mathias Lemperle-Kerr
  343.         "Ahhh the University of Illinois, what a joy..."
  344.  
  345. ------------------------------
  346.  
  347. End of INFO-ATARI16 Digest V89 Issue #761
  348. *****************************************
  349.